Dynamically changing a garbage collector in a managed runtime system

ABSTRACT

Machine-readable media, methods, and apparatus are described to dynamically change a garbage collector in a managed runtime system ( 1022 ). In some embodiments, a first garbage collector is loaded into the managed runtime system ( 1022 ) during a runtime stage of the managed runtime system ( 1022 ). The first garbage collector is further activated to manage a heap organization ( 203 ) of the managed runtime system ( 1022 ) in place of a second garbage collector of the managed runtime system ( 1022 ) during the runtime stage.

BACKGROUND

Garbage collection (GC) technology has been widely used in managedruntime systems, such as JAVA virtual machine (JVM) and Common LanguageRuntime (CLR). Usually, a garbage collector, as an executable binaryfile, is (inked statically or dynamically into the system during aninitialization stage of the system. However, once the garbage collectoris linked, it is typically unchangeable during a runtime stage of thesystem until restarting the system.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention described herein is illustrated by way of example and notby way of limitation in the accompanying figures. For simplicity andclarity of illustration, elements illustrated in the figures are notnecessarily drawn to scale. For example, the dimensions of some elementsmay be exaggerated relative to other elements for clarity. Further,where considered appropriate, reference labels have been repeated amongthe figures to indicate corresponding or analogous elements.

FIG. 1 illustrates an embodiment of a computing platform including amanaged runtime system.

FIG. 2 illustrates an embodiment of the managed runtime system.

FIGS. 3-5 illustrate an embodiment of a method of dynamically changingan old garbage collector in the managed runtime system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description describes techniques for dynamically changinga garbage collector in a managed runtime system. In the followingdescription, numerous specific details such as logic implementations,pseudo-code, methods to specify operands, resourcepartitioning/sharing/duplication implementations, types andinterrelationships of system components, and logicpartitioning/integration choices are set forth in order to provide amore thorough understanding of the current invention. However, theinvention may be practiced without such specific details. In otherinstances, control structures, gate level circuits and full softwareinstruction sequences have not been shown in detail in order not toobscure the invention. Those of ordinary skill in the art, with theincluded descriptions, will be able to implement appropriatefunctionality without undue experimentation.

References in the specification to “one embodiment”, “an embodiment”,“an example embodiment”, etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

Embodiments of the invention may be implemented in hardware, firmware,software, or any combination thereof. Embodiments of the invention mayalso be implemented as instructions stored on a machine-readable medium,that may be read and executed by one or more processors. Amachine-readable medium may include any mechanism for storing ortransmitting information in a form readable by a machine (e.g., acomputing device). For example, a machine-readable medium may includeread only memory (ROM); random access memory (RAM); magnetic diskstorage media; optical storage media; flash memory devices; electrical,optical, acoustical or other forms of propagated signals (e.g., carrierwaves, infrared signals, digital signals, etc.) and others.

FIG. 1 shows an embodiment of a computing platform 10 comprising amanaged runtime system. Examples for the computing platform 10 mayinclude a personal computer, a workstation, a server computer, apersonal digital assistant (PDA), a mobile telephone, a game console,and possibly other devices for transceiving and processing data.

The computing platform 10 may comprise one or more processors 101,memory 102, chipset 103, I/O devices 104, a firmware 105 and possiblyother components. The one or more processors 101 may be communicativelycoupled to various components (e.g., the chipset 103) via one or morebuses such as a processor bus. The processors 101 may be implemented asan integrated circuit (IC) with one or more processing cores that mayexecute codes under a suitable architecture, for example, includingIntel® Xeon™, Intel® Pentium™, Intel® Itanium™ architectures, availablefrom Intel Corporation of Santa Clara, Calif.

The memory 102 may store instructions and data in the form of a softwareapplication 1021, a managed runtime system 1022 and an operation system1023. Examples for the memory 102 may comprise one or any combination ofthe following semiconductor devices, such as synchronous dynamic randomaccess memory (SDRAM) devices, RAMBUS dynamic random access memory(RDRAM) devices, double data rate (DDR) memory devices, static randomaccess memory (SRAM), and flash memory devices.

The software application 1021 may be input from any suitable devices,such as the I/O devices 104. In other embodiments, the softwareapplications may be generated by other components within the computingplatform 10. Examples for the software application 1021 may compriseJAVA applications (e.g., JAVA bytecodes), .NET application (e.g., .NETCLI bytecodes), and applications compiled from or written in possiblyother programming languages (e.g., Smalltalk, Ruby).

The managed runtime system 1022 may run above the operating system 1023to execute the software application 1021. Examples for the manageruntime system 1022 may comprise a JAVA virtual machine from SunMicrosystems Inc., Mountain View, Calif., and a .NET virtual machineavailable from Microsoft® Corporation, Redmond, Wash.

The operation system 1023 may include, but is not limited to, differentversions of Linux®, Microsoft® Windows®, and real time operating systemssuch as VxWorks®, etc.

In an embodiment, the chipset 103 may provide one or more communicativepaths among the one or more processors 101, memory 102 and othercomponents, such as the I/O device 104 and firmware 105. The I/O devices104 may comprise a keyboard, mouse, network interface, a storage device,a camera, a blue-tooth device, and an antenna. The firmware 105 maystore BIOS routines that the computing platform 10 executes duringsystem startup in order to initialize the processors 101, chipset 103,and other components of the computing platform 10 and/or EFI routines tointerface the firmware 105 with an operating system 1023 of the computerplatform 10 and provide a standard environment for booting the operatingsystem 1023.

FIG. 2 shows an embodiment of the managed runtime system 1022. Accordingto the embodiment, the multitasking virtual machine 1022 may comprise acore module 201, an old garbage collector 202, a heap organization 203,a new garbage collector 204, and possibly other components.

The core module 201 may be responsible for file loading, file execution,garbage collector management, and possibly other functionalities. Thecore module 201 may comprise a loader 201 1, an execution engine 2012and a garbage collector manager 2013.

The loader 2011 may load files (including classes, interfaces, nativemethods) from various resources. For example, the loader 2011 may loadthe software application 1021, libraries and runtime environmentvariables from the managed runtime system vendor, programmer and anythird parties. In the embodiment, the loader 2011 may further loadgarbage collectors in various ways. For example, the loader 2011 mayload a garbage collector when starting up the system 1022, i.e., duringan initialization stage of the system, or when the system 1022 reallyfunctions, i.e., during a runtime stage of the system. In anotherexample, the loader 2011 may load the garbage collector as an executablebinary file or a non-binary file (e.g., a JAVA class file). Examples ofthe loader 2011 may comprise class loaders, native method interface, andpossibly other loading mechanisms.

The execution engine 2012 may execute the software application 1021 byutilizing the libraries, runtime environment variables and possiblyother assistant data. More specifically, the execution engine 202 maytranslate the software application and execute the translated codes byutilizing the libraries, runtime environment variables and possiblyother assistant data. Examples of the execution engine 2012 may comprisea JIT (just-in-time) compiler, an interpreter, a threading manager andpossibly other components.

The garbage collector manager (GC manager) 2013 may be responsible formonitoring a garbage collector (e.g., an old garbage collector 202) thatmay currently manage a heap organization 203 according to a certaingarbage collection algorithm, replacing the garbage collector withanother garbage collector (e.g., a new garbage collector 204) that maymanage the heap organization 203 according to another garbage collectionalgorithm and unloading the garbage collector if no longer needed.

The old garbage collector 202 may be responsible for managing the heaporganization 203 according to an old garbage collection algorithm. Forexample, the old garbage collector 202 may perform memory allocation andmemory reclamation (such as multi-blocks compaction, garbagereclamation, block defragmentation, reference patch, and so on) for theheap organization according to the old garbage collection algorithm.Examples of the old garbage collector may comprise a generationalgarbage collector, a semi-space garbage collector, and a mark-sweepgarbage collector.

The new garbage collector 204 may be responsible for managing the heaporganization 203 in place of the old garbage collector 203 according toa new garbage collection algorithm. For example, the new garbagecollector 204 may perform memory allocation and memory reclamation (suchas multi-blocks compaction, garbage reclamation, block defragmentation,reference patch, and so on) for the heap organization according to thenew garbage collection algorithm. Examples of the new garbage collector204 may comprise a generational garbage collector, a semispace garbagecollector, and a mark-sweep garbage collector.

The old garbage collector 202 and the new garbage collector 204 may linkwith the core module 201 through individual application programminginterfaces (API).

The heap organization 203 may be a memory structure to store data forthe managed runtime system 1022. For example, the heap organization 203may store program objects generated when executing a program and garbagecollector data used to assist a garbage collector perform garbagecollection. Size of the heap organization 203 may vary according tovarious factors, such as available memory size in the computing system,application memory requirement, and the algorithm design considerations.

The heap organization 203 may be divided into a number of separatedheaps. Each heap may comprise a number of logically contiguous memoryblocks, while no blocks overlap between two heaps. Different heaps mayhave different heap structures complying with different garbagecollector algorithms. For example, the heap organization 203 maycomprise an old heap 2031 complying with the old garbage collectionalgorithm and a new heap 2032 complying with the new garbage collectionalgorithm.

The garbage collector manager 2013 may monitor the performance of theold garbage collector 202 that may manage the heap organization 203according to the old garbage collection algorithm during the runtimestage of the system 1022. Then, the loader 2011 may load a new garbagecollector 204 into the system 1022 if the garbage collector manager 2013or any other party (such as a user) decides to replace the old garbagecollector 202 with the new garbage collector 204 to manage the heaporganization 203 according to a new garbage collection algorithm.

The garbage collector manager 2013 may invoke the old garbage collector202 to garbage collect the heap organization 203 and reclaim ‘dead’objects from the heap organization 203 while keeping ‘live’ objects inthe heap organization 203. The garbage collector-manager 2013 maytransfer a part of the heap organization 203 from the old garbagecollector 202 to the new garbage collector 204 for ‘live’ objectmigration before unloading the old garbage collector 202.

The reasons for the transferring may comprise that the heap structuresfor the old garbage collector 202 and the new garbage collector 204 aredifferent and the ‘live’ objects should be migrated to comply with thenew heap structure for the new garbage collector 204. As a result of thetransferring, the old garbage collector 202 and new garbage collector204 may manage different parts of the heap organization 203.

For example, the old garbage collector 202 may manage the old heap 2031and the new garbage collector 204 may manage the new heap 2032. The‘Live’ object migration may be implemented in two ways: moving the‘live’ objects from the old heap 2031 into the new heap 2032 withoutchanging the object layout; or, allocating new objects in the new heap2032 and copy fields from the ‘live’ objects of the old heap into thenew objects of the new heap.

After all of the ‘live’ objects are migrated into the new heap 2032, thegarbage collector manager 2013 may unload the old garbage collector 202from the managed runtime environment 1022, and transfer the old heap2031 to the new garbage collector 204.

Other embodiments may implement other technologies for the structure ofthe managed runtime environment 1022. In an embodiment, the garbagecollector manager 2013 may determine not to transfer a part of the heaporganization 203 before unloading the old garbage collector 202. Thereasons for not transferring may comprise that the heap structures ofthe old garbage collector 202 and the new garbage collector 204 may bethe same or similar with each other, and therefore, there are no needsto move the ‘live’ objects. As a result of not transferring, the oldgarbage collector 202 and the new garbage collector 204 may manage acommon part of the heap organization 203 before unloading the oldgarbage collector 203.

In another embodiment, the garbage collector manager 2013 may functionas a garbage collector to manage a heap, e.g., a root heap (not shown inFIG. 2) of the heap organization 203, such as memory allocation andmemory reclamation of the root heap. Since the garbage collector manager2013 acts as a garbage collector, the core module 201 and the heaporganization 203 may be enough to form a complete managed runtimesystem, even without the old garbage collector 202 and/or the newgarbage collector 204.

Therefore, the old garbage collector 202 and/or the new garbagecollector 204 may be loaded into the system 1022 as a user application,such as in form of JAVA class files or NET PE files. In such case, thegarbage collector manager 2013 may allocate program objects generatedwhen executing the loaded files of the old or new garbage collector intothe root heap, and reclaim the program objects from the root heap whenunloading the old or new garbage collector.

In yet another embodiment, the garbage collector manager 2013 may notunload the old garbage collector 202, but activate the new garbagecollector 204 to manage the heap organization 203 with the old garbagecollector 202. The combination of the old and new garbage collectors maybe called as a hybrid garbage collection. For example, the old garbagecollector 202 may be a semispace garbage collector and the new garbagecollector 204 may be a generational garbage collector. Therefore, thehybrid garbage collector may be a generational/semispace garbagecollector.

FIGS. 3-5 illustrate an embodiment of a method of dynamically changingan old garbage collector 202 in the managed runtime system 1022.

Referring to FIG. 3, in block 301, the garbage collector manager 2013 orany other party (e.g., the user) may decide to replace the old garbagecollector 202 functioning according to the old garbage collectionalgorithm with the new garbage collector 204 functioning according tothe new garbage collection algorithm during the system runtime stage.The garbage collection manager 2013 may make such decision according tovarious factors, such as characterizations of the applications runningabove the system 1022 and/or hardware (e.g., processor, memory, etc.)running under the system 1022. For example, performance of the softwareapplication SPECjbb2000 may be good with generational garbage collectorwhen heap size is modest, but may be better with semi-space GC when heapsize is large. The system runtime stage may comprise the stage that thesystem 1022 operates to finish an application execution.

In bock 302, the garbage collector manager 2013 may stop the world, forexample, threads of the application running above the system 1022 may besuspended. In block 303, the loader 2011 may load the new garbagecollector 204 into the system 1022. The loader 2011 may load the newgarbage collector 204 in executable binary files. However, the loader2011 may load the new garbage collator 204 in non-binary files, such asJAVA class files or CLI bytecode files. In such case, the garbagecollector manager 2013 may load program objects representing thenon-binary files of the new garbage collector 204 into the heaporganization 203.

In block 304, the garbage collector manager 2013 may link a part orwhole of the new garbage collector 204 by adhering to a part or whole ofthe API interface of the new garbage collector 204. For example, thegarbage collector manager 2013 may link the initialization andallocation functions of the new garbage collector 204. Then, in block305, the garbage collector manager 2013 may initialize the new garbagecollector 204. In block 306, the garbage collector manager 2013 mayinvoke the old garbage collector 202 to perform a garbage collection byreclaiming the ‘dead’ objects from the heap organization 203 whilekeeping the ‘live’ objects in the heap organization 203. The ‘live’objects may comprise the objects that may be reachable through a rootreference stored in a root set, e.g., the objects referred by a rootreference or another live object. The ‘dead’ objects may comprise theobjects that may not be reachable through the root reference in the rootset. The ‘live’ objects may be structured in an old layout that complieswith the old garbage collection algorithm.

FIG. 4 continues to illustrate the embodiment of the method of changingthe old garbage collector 202. In block 401, the garbage collectormanager 2013 may determine whether the old garbage collector 202 and thenew garbage collector 204 could share a common part of the heaporganization 203. As described above, if the heap structure for the oldgarbage collector 202 is the same or similar with that for the newgarbage collector 204, the two garbage collectors may share a commonpart of the heap organization 203. For example, if the old garbagecollector 202 is a generational garbage collector with card tablesupport and the new garbage collector 204 is a generational garbagecollector with remember set support, the two garbage collectors may havethe same heap structure, and therefore, may share the heap organization203.

In another example, the old garbage collector is a semispace garbagecollector that may require the heap organization 203 to be divided intotwo areas of equal space, i.e., from-space and to-space, and the newgarbage collector is a generational garbage collector that may requirethe heap organization to be divided into two or more areas, each ofwhich may serve one ‘generation’ of objects. In such case, the oldgarbage collector 202 and the new garbage collector 204 may have thesimilar heap structure and thus may share a common part of the heaporganization 203, e.g., the from-space.

If both garbage collectors 202 and 204 share the common part of the heaporganization 203, then in block 402, the garbage collector manager 2013may determine whether to change the layout of the ‘live’ objectsidentified in block 306. Different garbage collection algorithms mayhave different requirements on object layouts. If the garbage collectormanager 2013 determines to change the layout of the ‘live’ objects, thenin block 403, the garbage collector manager 2013 may invoke the newgarbage collector 204 to allocate new objects having the new objectlayout in the common part of the heap organization 203. The garbagecollector manager 2013 may further invoke the old garbage collector 202to find fields of the ‘live’ objects, invoke the new garbage collector204 to find fields of the new objects, and copy values of the fields ofthe ‘live’ objects into the fields of the new objects in block 404.

Then, in block 409, the garbage collector manager 2013 may update theobject references referring to the ‘live’ objects into the-objectreferences referring to the new objects. For example, the new garbagecollector 204 may provide the old garbage collector 202 with positionsof the new objects so that the old garbage collector 204 may update theobject references with the new object positions so that the objectreferences may refer to the new objects.

However, if the garbage collector manager 2013 determines in block 401that the heap structures for the both garbage collectors are differentthat they can not share the common part of the heap organization 203,the garbage collector manager 2013 may rearrange the heap organization203 to transfer a part of the heap organization 203 to the new garbagecollector 204 in block 405. More specifically, the heap organization 203may be divided into two heaps, i.e., an old heap 2031 having a structurecomplying with the old garbage collector algorithm, and a new heap 2032having a structure complying with the new garbage collector algorithm.For example, if the old garbage collector is a semispace garbagecollector, and the new garbage collector is a mark-sweep collector, thegarbage collector manager may rearrange the to-space complying with themark-sweep algorithm while remaining the from-space complying with thesemispace algorithm.

Then, in block 406, the garbage collector manager 2013 may determinewhether to change the layout of the ‘live’ objects stored in the oldheap 2031. If the garbage collector manager 2013 determines to changethe layout of the ‘live’ objects, then in block 407, the garbagecollector manager 2013 may invoke the new garbage collector 204 toallocate a new object in the new heap 2032. In block 408, the garbagecollector manager 2013 may further invoke the old garbage collector 202to find fields of the ‘live’ objects in the old heap 2031, invoke thenew garbage collector 204 to find fields of the new objects in the newheap 2032, and copy values of the fields of the ‘live’ objects into thefields of the new objects. Then, in block 409, the garbage collectormanager 2013 may update the object references that may refer to the‘live’ objects in the old heap 2031 into the object references that mayrefer to the new objects in the new heap 2032.

However, if the garbage collector manager 2013 determines not to changethe layout of the ‘live’ objects in block 406, then the garbagecollector manager 2013 may determine whether to move the ‘live’ objects.Since the heap organization 203 has been rearranged into the old heap2031 and the new heap 2032 that may be respectively managed by the oldgarbage collector 202 and the new garbage collector 204, there may existneeds to move the ‘live’ objects from the old heap 2031 into the newheap 2032.

If it is determined to move the ‘live’ objects, the garbage collectormanager 2013 may invoke the new garbage collector 204 to move the ‘live’objects from the old heap 2031 into the new heap 2032 in block 411.Then, in block 409, the garbage collector manager 2013 may update theobject references that may refer to the ‘live’ objects in the old heap2031 into the object references that may refer to the ‘live’ objects inthe new heap 2032.

FIG. 5 continues to illustrate the embodiment of the method of changingthe old garbage collector 202.

In block 501, the garbage collector manager 2013 may migrate garbagecollector managed data within the heap organization 203 if necessary.The garbage collector managed data may be used by a garbage collectorfor memory management such as memory allocation and memory reclamation.The migration of the garbage collector managed data may comprise movingthe garbage collector managed data and/or changing the layout of thegarbage collector managed data. Under certain circumstances, the garbagecollector managed data may be migrated, for example, if the heaporganization is rearranged into the old heap 2031 and the new heap 2032,and/or if the layout of the garbage collector managed data for the oldgarbage collector 202 is different from that for the new garbagecollector 204.

Then, the garbage collector manager 2013 may link the rest of the APIinterface of the new garbage collector 204 in block 502. In block 503,the garbage collector manager 2013 may unload the old garbage collector202. For example, the garbage collector manager 2013 may unlink the APIinterface of the old garbage collector 202. If the old garbage collector202 was loaded as a non-binary file into the system 1022, the garbagecollector manager 2013 may reclaim program objects generated whenexecuting the class file of the old garbage collector 202 from the heaporganization 203.

In block 504, if the heap structure for the old garbage collector 202 isdifferent from that for the new garbage collector 204, the new garbagecollector 204 may rearrange the heap organization 203 into a heapstructure complying with the new garbage collection algorithm. Forexample, the new garbage collector 204 may configure the old heap 2031from an old heap structure into a new heap structure. However, block 504may be omitted if the heap structures for the both garbage collectorsare the same or similar.

Finally, in block 505, the garbage collector manager 2013 may resume theworld, e.g., resume the application threads that were suspended in block302.

Although the present invention has been described in conjunction withcertain embodiments, it shall be understood that modifications andvariations may be resorted to without departing from the spirit andscope of the invention as those skilled in the art readily understand.Such modifications and variations are considered to be within the scopeof the invention and the appended claims.

1. A method, comprising: loading a first garbage collector into amanaged runtime system during a runtime stage of the managed runtimesystem; and activating the first garbage collector to manage a heaporganization of the managed runtime system in place of a second garbagecollector of the managed runtime system during the runtime stage.
 2. Themethod of claim 1, wherein the first garbage collector is a non-binaryfile.
 3. The method of claim 2, further comprising storing a programobject generated when running the non-binary file of the first garbagecollector into the heap organization.
 4. The method of claim 1, furthercomprising unloading the second garbage collector from the managedruntime system.
 5. The method of claim 4, wherein the activating furthercomprises: invoking the second garbage collector to garbage collect theheap organization and to identify a live second object in a second partof the heap organization, wherein the second part of the heaporganization complies with a second garbage collection algorithm of thesecond garbage collector; and configuring a first part of the heaporganization to comply with a first garbage collection algorithm of thefirst garbage collector.
 6. The method of claim 5, wherein theactivating further comprises: moving the live second object from thesecond part of the heap organization to the first part of the heaporganization; and editing a reference referring to the live secondobject in the second part of the heap organization to another referencereferring to the live second object in the first part of the heaporganization.
 7. The method of claim 5, wherein the activating furthercomprises: allocating a first object in the first part of the heaporganization, wherein the first object has a first layout complying withthe first garbage collection algorithm and the live second object has asecond layout complying with the second garbage collection algorithm;copying data from the live second object into the first object; editinga first reference referring to the live second object in the second partof the heap organization to a second reference referring to the firstobject in the first part of the heap organization; and releasing thelive second object from the second part of the heap organization.
 8. Themethod of claim 5, wherein the activating further comprises: configuringthe second part of the heap organization to comply with a first garbagecollection algorithm of the first garbage collector.
 9. The method ofclaim 4, wherein the activating further comprises: invoking the secondgarbage collector to garbage collect the heap organization and toidentify a live second object in the heap organization, wherein the livesecond object has a second layout complying with a second garbagecollection algorithm of the second garbage collector; allocating a firstobject in the heap organization, wherein the first object has a firstlayout complying with the first garbage collection algorithm of thefirst garbage collector; copying data from the live second object intothe first object; editing a reference referring to the live secondobject to another reference referring to the first object; and releasingthe live second object from the heap organization.
 10. A method,comprising: loading a first garbage collector into a managed runtimesystem during a runtime stage of the managed runtime system; andactivating the first garbage collector to manage a heap organization ofthe managed runtime system with a second garbage collector of themanaged runtime system during the runtime stage.
 11. The method of claim10, wherein the activating further comprises: configuring the heaporganization to comply with a hybrid garbage collection algorithm of thefirst garbage collector and the second garbage collector.
 12. The methodof claim 11, wherein the activating further comprises: invoking thesecond garbage collector to garbage collect the heap organization andidentify a live second object in the heap organization; allocating ahybrid object which has a hybrid layout complying with the hybridgarbage collection algorithm; copying data from the live second objectto the hybrid object; and releasing the live second object from the heaporganization.
 13. A managed runtime system, comprising: a heaporganization; a first garbage collector to manage the heap organization;a loader to load a second garbage collector during a runtime stage ofthe managed runtime system; and a garbage collector manager to activatethe second garbage collector to manage the heap organization in place ofthe first garbage collector during the runtime stage.
 14. The managedruntime system of claim 13, wherein the loader further loads the secondgarbage collector as a non-binary file, and the garbage collectormanager further allocates a program object generated when running thenon-binary file of the second garbage collector into the heaporganization.
 15. The managed runtime system of claim 13, wherein thegarbage collector manager further unloads the first garbage collectorfrom the managed runtime system.
 16. The managed runtime system of claim15, wherein the garbage collector manager further: invokes the firstgarbage collector to garbage collect the heap organization and toidentify a live first object in a first part of the heap organization,wherein the first part of the heap organization complies with a firstgarbage collection algorithm of the first garbage collector; andconfigures a second part of the heap organization to comply with asecond garbage collection algorithm of the second garbage collector. 17.The managed runtime system of claim 16, wherein the garbage collectormanager further: moves the live first object from the first part of theheap organization to the second part of the heap organization; and editsa reference referring to the live first object in the first part of theheap organization to another reference referring to the live firstobject in the second part of the heap organization.
 18. The managedruntime system of claim 16, wherein the garbage collector managerfurther: allocates a second object in the second part of the heaporganization, wherein the second object has a second layout complyingwith the second garbage collection algorithm and the live first objecthas a first layout complying with the first garbage collector algorithm;copies data from the live first object into the second object; edits areference referring to the live first object in the first part of theheap organization to another reference referring to the second object inthe second part of the heap organization; and releases the live firstobject from the first part of the heap organization.
 19. The managedruntime system of claim 16, wherein the garbage collector managerfurther configures the first part of the heap organization to complywith the second garbage collection algorithm.
 20. The managed runtimesystem of claim 15, wherein the garbage collector manager further:invokes the first garbage collector to garbage collect the heaporganization and to identify a live first object in the heaporganization, wherein the live first object has a first layout complyingwith a first garbage collection algorithm of the first garbagecollector; allocates a second object in the heap organization, whereinthe second object has a second layout complying with a second garbagecollection algorithm of the second garbage collector; copies data fromthe live first object into the second object; edits a referencereferring to the live first object to another reference referring to thesecond object; and releases the live first object from the heaporganization.
 21. A managed runtime system, comprising: a heaporganization; a first garbage collector to manage the heap organization;a loader to load a second garbage collector during a runtime stage ofthe managed runtime system; and a garbage collector manager to activatethe second garbage collector to manage the heap organization with thefirst garbage collector during the runtime stage.
 22. The managedruntime system of claim 21, wherein the garbage collector managerfurther configures the heap organization to comply with a hybrid garbagecollection algorithm of the first garbage collector and second garbagecollector.
 23. The managed runtime system of claim 21, wherein thegarbage collector manager further: invokes the first garbage collectorto garbage collect the heap organization and to identify a live firstobject in the heap organization; allocates a hybrid object which has ahybrid layout complying with a hybrid garbage collection algorithm ofthe first garbage collector and second garbage collector; copies datafrom the live first object to the hybrid object; and releases the livefirst object from the heap organization.
 24. A machine-readable mediumcomprising a plurality of instructions which when executed result in amanaged runtime system: loading a garbage collector as a non-binary fileinto the managed runtime system during a runtime stage of the managedruntime system; and allocating a program object generated when runningthe non-binary file of the garbage collector into a heap organization ofthe managed runtime system.
 25. The machine-readable medium of claim 24,wherein the non-binary file is a JAVA class file.
 26. Themachine-readable medium of claim 24, wherein the plurality ofinstructions further result in the managed runtime system: unloading thegarbage collector from the managed runtime system; and reclaiming theprogram object from the heap organization.